软件架构的23个基本原则
软件体系架构基于一组适用于各种软件系统的基本原则，有经验的架构师知道这些原则，并且能够在软件产品的正确位置实现特定的原则。下面我们快速浏览一下架构师日常遵循的基本原则。
1. 依赖倒置（Dependency Inversion）
这一原则表明依赖的方向应该是抽象的，而不是具体实现。如果编译时依赖在运行时执行的方向上流动，就形成了直接依赖。通过依赖倒置，可以反转依赖控制的方向。下面的文章更深入的讨论了这一原则：
https://medium.com/p/de6abf20e423
2. 关注点分离（Separation of Concerns）
这一原则指出，软件系统应该按照所做的工作类型来划分。比方说可以按照业务逻辑、基础设施或用户界面划分为不同的部分。通过将系统划分为基于不同活动区域的不同部分，使得开发/测试/部署更加容易。SoC是软件架构模式（如领域驱动设计、六边形架构、整洁架构）背后的驱动力。
3. 控制反转（Inversion of Control）
该原则类似于依赖倒置原则，但适用于更广泛的背景。IoC反转了由不同的第三方框架（如Spring Framework）管理的控制流。与传统Java EE程序（由开发工程师按程序初始化Beans）不同，Spring控制Bean的配置，这意味着控制倒置。
4. 依赖注入（Dependency Injection）
该原则意味着依赖应该在运行时通过构造函数注入。在下面的例子中，Action Interface通过HumanAction Implementation注入到Human类中，从而决定在运行时实现哪个特定的动作。这种技术提供了控制依赖的灵活性：
package az.alizeynalli.di;
public interface Action {
void do();
}
public class HumanAction implements Action {
@Override
public void do() {
System.out.print("run");
}
}
public class Human {
Action action;
public Human(Action action) {
this.action = action;
}
@Override
public void do() {
actoin.do();
}
}
public static void main(String[] args) {
Human human = new Human(new HumanAction);
human.do();
}
该原则的主要思想是限定软件系统的每个构建块只承担唯一的责任。无论构建块的作用域是什么，是插件、包、类、函数，甚至是变量，应该只有一个职责。这篇文章更深入的讨论了这一原则：
https://medium.com/p/6b886f6d943e
6. DRY（Don’t Repeat Yourself）
该原则旨在通过避免重复代码来消除冗余。如果存在针对某些行为的现有功能，则应该重复使用，而不是在多个实例中拷贝相同的代码片段。
每个知识片段在系统中都必须有单一、明确、权威的表示。
7. 开闭原则（Open-Closed）
软件构件应该对扩展开放，对修改关闭。
这一原理的简单描述首先是由Bertrand Meyer提出的。每次都需要修改的软件系统只会变得一团糟，并且这种混乱的程序很容易在每次修改时出现错误。每个新功能都应该最大限度的增加新代码，最小限度减少旧代码的更改，理想情况下对旧代码的更改为零。
8. 持久化透明（Persistence Ignorance）
持久化透明的理念是，代码应该不受任何数据库或持久性技术的影响。业务逻辑应该与任何技术无关。如果明天，有更好、更有效、更便宜的持久化技术，应该能够以不影响上层抽象的方式改变系统的这一部分。
9. YAGNI
You ain’t gonna need it. 这一原则试图避免软件系统的过早优化。开发人员通常会在系统中过度设计一些东西，以期在将来的某个时候会有帮助，但这一时刻往往不会到来。
10. 童子军规则（Boy Scout Rule）
在离开的时候要让露营地比来的时候更干净。
这里的主要思想是，当开发时遇到反模式，要坚持重构代码。随着时间的推移，这会提高代码质量。
11. 里氏替换原则（Liskov-Subsititution）
如果对于每个类型为S的对象o1，都有一个类型为T的对象o2，这样对于用T定义的所有程序P，当o1取代o2时，P的行为不变，那么S就是T的子类型。
Barbara Liskov的这个定义可能听起来很混乱，但本质上这个原则简单易懂。如果重述上面的定义，该原则的意思是: 在使用继承时，继承的层次结构应该在功能和业务逻辑方面保持一致。子类应该是可以相互替换的，并且不能改变父类的行为。作为一个简单的例子，可以用“臭名昭著的正方形/矩形”问题。其中正方形不应该是矩形的子类型，因为这两个几何形状的高度和长度的定义是不同的（正方形的高度和长度是相等的，而矩形的高度和长度是不同的）。
12. 封装（Encapsulation）
软件系统的不同构建块应该通过封装来限制外界对其组件的访问，可以通过在类范围内设置组件为私有或在插件范围内设置访问限制来实现（就Java而言），从而隐藏信息。
13. 松耦合（Loose Coupling）
软件架构中最重要的原则之一是松耦合，这一原则表明软件系统的依赖关系应该松散，系统的一部分发生变化，对其他部分的影响应该最小。松耦合可以通过依赖倒置、异步消息中间件、事件源等实现。下面的文章深入探讨了软件工程中不同形式的耦合：
https://medium.com/p/4d5cf2b3e99e
14. 内聚（Cohesion）
内聚是指模块内的元素依赖的程度。某种意义上说，是对类的方法和数据以及该类所服务的某种统一目的或概念之间关系强度的度量。
构建高内聚的类是一种最佳实践，有利于实现单一责任原则、松耦合等。
15. 接口隔离（Interface Segregation）
接口隔离原则指出，不应强迫客户端依赖不使用的方法。
应该明确的是，这个原则主要适用于静态类型的编程语言，如Java、C等。在像Python或Ruby这样的动态类型语言中，这个原则没有太大意义。
可以想象这样一种情况，我们的Income和Expense用例都依赖于支持这两种用例的业务逻辑功能。因此Income用例的很多依赖都和Expense用例相关，而Expense用例的依赖情况也有相同的问题。基于以上讨论，ISP违规情况如下：
package az.alizeynalli.cashflow.core.service;
public interface ConverterService {
Income convertIncome(Income income);
Expense convertExpense(Expense expense);
}
@Component
public class ExpenseConverterServiceImpl implements ConverterService {
@Override
public Income convertIncome(Income income) {
throw new UnsupportedOperationException();
}
@Override
public Expense convertExpense(Expense expense) {
// convert expense here
return expense;
}
}
@Component
public class IncomeConverterServiceImpl implements ConverterService {
@Override
public Income convertIncome(Income income) {
// convert income here
return income;
}
@Override
public Expense convertExpense(Expense expense) {
throw new UnsupportedOperationException();
}
}
限界上下文是领域驱动设计的中心模式。通过将大型应用程序或组织分解为单独的概念模块，提供了一种处理复杂性的方法。每个概念模块代表一个上下文，该上下文与其他上下文分离（因此是有边界的），并且可以独立发展。理想情况下，每个限界上下文应该可以自由的为其中的概念选择自己的名称，并且应该独占的访问自己的持久化存储。
17. 依赖稳定原则（Stable Dependencies）
这一原则指出，软件系统的不同构建块应该只依赖于可靠、稳定的工件。这个原则在Docker镜像术语中更有意义，当我们从docker hub导入不同的依赖时，甚至不知道它们是否可靠/稳定。
18. 多态（Polymorphism）
这实际上属于面向对象编程的4大支柱，鼓励使用可以以多种形式提供的接口，多态性意味着具有多种形式的实体。
19. 模块化（Modularization）
模块化是将软件系统划分为多个独立模块的过程，每个模块独立工作。这一原则是应用于软件系统静态架构的单一职责分离原则的另一种形式。
20. 抽象（Abstraction）
这也属于面向对象编程的四大支柱:
在研究物体或系统时去除物理的、空间的或时间的细节或属性以集中注意力于更重要的部分，本质上与泛化过程相似。
21. KISS（Keep It Simple, Stupid）
按照字面意思理解，这一原则激励工程师保持代码简单和愚蠢（容易理解），避免他人误解。
22. 增量/迭代方法（Incremental/Iterative Approach）
这一原则是敏捷软件开发宣言的基础，基于软件系统应该以增量和迭代的方式开发的思想，每一次迭代都会增加系统功能并保证其运行。
23. 最少知识原则（Least Knowledge）
或者叫信息嫉妒（information envying），是封装或信息隐藏原则的另一个术语，规定软件系统的不同部分应该只拥有需要的知识。
本文源自公众号DeepNoMind，分布式实验室已获完整授权。
推荐阅读：